［レポート］メトリックはいかにして見え續ける樣になったか #devio2022

こんにちは、アライアンス統括部のきだぱんです。
2022年7月26日〜29日開催の技術カンファレンスDevelopersIO 2022のセッションレポートとなります。
当記事では、DevelopersIO 2022のセッションの中から、メトリックはいかにして見え續ける樣になったかというセッションのレポートをお届けします。

それではいってみましょう！！

本編について

動画

本編はこちらからご覧いただけます。

セッション概要

概要

2021年9月13日にカスタムメトリックが強化されたMackerel。2つの大きな困難をどう乗り越えカスタムメトリック強化を実現したのかご紹介します。

登壇者は、株式会社はてなの.｡oO(さっちゃんですよヾ(〃l _ l)ﾉﾞ☆)さんです。

アジェンダ

• Mackerelとは
• どうやってカスタムメトリックを強化したのか

レポート

mackerelとは

mackerelとはクラウド時代に最適な監視モデルと誰でも簡単に使えるUIによって、システムの運用・監視にチームで取り組み文化を育むSaaS型サーバー監視サービスです。
Mackerel公式サイトの下記をご覧ください。↓

カスタムメトリックの強化

2021年9月にmackerelのカスタムメトリックを強化し、退役後もカスタムメトリックをグラフで確認することが可能になりました。

mackerelには、カスタムメトリックとシステムメトリックがあり、以前はシステムメトリックのみ退役後もロールグラフを確認できましたが、アップデートにより、カスタムメトリックでも同様にロール用のカスタムメトリックを通して退役後のグラフを確認できるようになりました。
しかし、実装をする上で大きな二つの課題が出てきたようです。

いかにしてホストメトリックとロールメトリックをうまく組み合わせるか

ホストメトリックとロールメトリックをどのように組み合わせるのか。 以前から退役後のグラフを確認できていたシステムメトリックでは、左側のリレーショナルデータベースと右側の時系列データベースからそれぞれデータを持ってきて表示させていました。

しかし、カスタムメトリックでは、ユーザーが自由にロールを増やすことが出来ます。
そのため、今どんなホストがあるのかは分かるが、どんなロールメトリックがあるのかまでは旧形体では分かりませんでした。
ロールは何年も存在し、そこに新しいホストが追加されたり、古いホストが退役されたりする為、次々とロールが増えていきます。
そのため、
どんなロールメトリックがあるかわからない！

そこで！

• カスタムメトリックはどのロールにどのようなメトリックがあるかは保存しない
• ホストは、最近のホスト(今あるメトリックと退役したばかりのメトリック)を集めることで全体のメトリックと極端には異ならないため
  ≒近似できる
  それにより、ロールメトリックの取得が可能になりました。

書き込み負荷は大丈夫か

新しくカスタムメトリックをロールメトリックとしても保存することにしたため、保存するデータ量は以前より増加します。
その場合の書き込み負荷についてが二つ目の課題です。
負荷調査のため、一部のカスタムメトリックをロールメトリックに書き込みをした結果、時系列DBの使うRadis ClusterのCPU Engineが一気に100%までいき、その後慌ててロールバックする結果に。

時系列DBの仕組みは以下の通りです。

• 書き込み系と読み出し系があり、それぞれKinesisDataStreamsに書き込み、ECSクラスターから計算して読み込む
• KinesisDataStreamsに書き込まれたデータはまずLmbdaに取り出し、RedisClusterに書き込んだ後にストレージに保存される
• ストレージは三段階あり、新しいメトリックはRadisCluster、次にDynamoDB。次にS3の順に移動していきます。

今回、負荷が大きかった場所は、RedisClusterに書き込む部分です。
現状は、1nodeだけ分散されずに大きく負荷がかかっているため、nodeを増やしても解決せず、スケールされません。
※ RedisClusterとは
複数台のRadis nodeにkeyに従ってdateを分散する。
Keyをx{y}zとするとy(hassh tag)を見て保存するnodeを決める。yが同じだと、Keyが異なっても同じRedis nodeに保存される。 同時に読み書きするdateを同じnodeに保存すると高パフォーマンスとなる。

そこで、以下のようにロールメトリックのKey構造を変更し、書き込み負荷について課題解決されました。

ロールメトリックの旧Key構造
{オーガニゼーションID.r.1.サービスID}.ロールID.スロット番号.メトリック名
(RedisCluster hassh tagにホストIDまでしか含まれていない、数万ものカスタムメトリックが同じRadis nodeに読み書きされてしまい分散されない。)

↓↓↓

ロールメトリックの新Key構造
{オーガニゼーションID.r.1.サービスID.ロールID.スロット番号}.メトリック名
スロット番号までhash tagに含めることで、ホスト毎にカスタムメトリックを保存するRedis nodeが決められる。
RedisClusterに新しいものはどんどん保存されていくが、その後はそれぞれのメインストレージ(DynemoDB)に保存されるため、RedisCluster自体には一週間程しか保存しない為、移行が可能。
DynemoDBへ移す前、ECSで読みだした後にhash tag{}を取り除くので、RedisClusterの外に影響しないため、Keyの構造は変わっていない。

この構造に変更し、書き込み負荷についての課題は解決されました。

まとめ

上記の課題を乗り越え、mackerelではカスタムメトリックを強化し、退役後もカスタムメトリックをグラフで確認することが可能になりました。
私もmackerelユーザーですが、このような仕組みになっていたとは今回初めて知りました。カスタムメトリックは自分の環境に合わせて監視することが出来るので、退役後も確認できるのは、とても便利な機能です！！
Mackerelや今回のイベントDevelopersIO2022に関するブログも沢山展開されていますので、是非こちらもご覧ください。
Mackerel の記事一覧 | DevelopersIO
DevelopersIO 2022 の記事一覧 | DevelopersIO
このレポートがどなたかのお役に立てば幸いです。